À la recherche des licornes:

les limites du théorème CAP

Forum PHP - Paris 2021
2021-10-22

Qui suis-je?

  • Lætitia Avrot
  • mydbanotebook.org
  • Contributrice PostgreSQL
  • fondatrice #PostgresWomen
  • EDB Senior Database Consultant
  • @l_avrot
Image by Anemone123 from Pixabay

La chasse à la licorne

  • Perte de données et de disponibilité
  • Les théorèmes CAP et PACELC
  • Quelques architectures typiques
Image by João Paulo from Pixabay

0 perte de données

  • N'existe pas
  • Désolée :-)
  • Différentes significations
Image by Pete Linforth from Pixabay

Perte de disponibilité admissible

Disponibilité
voulue
jour semaine an
100% 0 0 0
99.999% <0.9s 6s <5min
99.99% <8s 1min 52min
99.9% 1.5min 10min 8h45min
99.999% en journée 0.4s 3s <3min

Les pannes font partie de la vie

Image by WikiImages from Pixabay

Les pannes font partie de la vie

Image by WikiImages from Pixabay

Les pannes font partie de la vie

Image by WikiImages from Pixabay

CAP theorem

Lors de la conception de web services distribués, trois propriétés sont la plupart du temps souhaitées: la cohérence, la disponibilité, et la tolérance au partitionnement réseau. Il est impossible d'atteindre les trois simultanément.

CAP theorem

La cohérence

Chaque nœud verra la dernière version (commitée) des données.
Image by Andrew Martin from Pixabay

La disponibilité

Le système fournira toujours une réponse différente d'un message d'erreur.
Image by Andrew Martin from Pixabay

Le partitionnement réseau

Le réseau pourra perdre un grand nombre aléatoire de messages envoyés par un nœud à un autre nœud sans altérer les réponses du système.

Le théorème CAP

  • Il est impossible d'avoir les trois
  • On peut atteindre 2 propriétés
  • Et tendre vers la troisième
Les SGBDR sont CA
⟶ Vrai et faux
Les SGBDR à un seul nœud sont CA
Image by Gerd Altmann from Pixabay
Les SGBDR sont CA
⟶ Vrai et faux
Les SGBDR avec réplication streaming asynchrone sont AP
Image by Gerd Altmann from Pixabay
Les SGBDR sont CA
⟶ Vrai et faux
Les SGBDR avec réplication streaming synchrone sont presque C et presque P et pas tout à fait A
Image by Gerd Altmann from Pixabay

PACELC theorem

En cas de partitionnement réseau (P) dans un système informatique distribué, il faut choisir entre la disponibilité (A) et la cohérence (C),
mais encore (E), même quand le système tourne normalement en l'absence de partition réseau, il faut choisir entre la latence (L) et la cohérence (C).
Image by congerdesign from Pixabay

La latence

La latence est le laps de temps nécessaire au système pour répondre avant qu'il n'y ait un timeout.
Image by Pexels from Pixabay

Quel est le plan?

  • PostgreSQL
  • Ce ne sont que des exemples
  • Attention au maillon le plus faible


Une bonne architecture est une architecture KISS!
Image by Free-Photos from Pixabay

Aparté sur le vocabulaire

  • Reine: serveur qui écrit et lit
  • Princesse: serveur qui attend de prendre la place de la reine
  • Ouvrière: Serveur qui sert des requêtes de lecture

Perte de données

PDMA Architecture à envisager
≥ 15min Backup physique + archivage des logs
≥ 1min Backup physique + archivage des logs
+ Princesse asynchrone
≥ 200ms Backup physique + archivage des logs
+ Princesse synchrone (+ asynchrone)
0 Pas possible 😏
Image by Free-Photos from Pixabay

Haute disponibilité

DMIA Architecture à envisager
≥ 24h Backup physique + archivage des logs (en fonction du temps de restore)
≥ 30min Princesse + failover manuel
≥ 5min Princesse + failover automatique

Haute disponibilité

DMIA Architecture à envisager
≥ 1min/30s Multi-reines
0 Pas possible 😏

Une architecture classique

Pourquoi classique?

  • Correspond à beaucoup de budgets
  • Un ou deux datacentre•s
  • La plupart du temps, ~30 minutes DMIA
  • La plupart du temps, ~200ms PDMA

Les bases de données

Les bases de données

  • Réplication streaming asynchrone
  • Un ou deux datacentre•s
  • Dénomination blue/green
  • Pooler de connexions

Les outils autour

Les outils autour

  • Monitoring
  • Backup
  • Test des backups
  • Fichiers de configuration

Lectures rapides prioritaires

Un peu de contexte

  • Données médicales
  • Augmenter la disponibilité en lecture
  • Diminuer la perte de données

Architecture de base

Architecture de base

  • 1 Reine
  • 1 Princesse
  • Plusieurs ouvrières

Les backups

Les backups

  • Sauvegarde de la configuration sur un git
  • Sauvegarde physique + archivage des logs
  • Tests quotidiens sur une "cold" standby

Doublons les datacentres

Doublons les datacentres

  • Princesses synchrones avec un quorum de 1
  • Redondance des sauvegardes

...Et tout le reste!

...Et tout le reste!

  • Ajout d'un serveur de monitoring
  • Gestion des données historiques
    • Archivage online
    • Archivage offline

Un compromis acceptable

Favoriser la disponibilité

Favoriser la disponibilité

  • Client bancaire
  • Beaucoup de transactions en écriture

BDR

BDR

  • 4 nœuds en écriture
  • Seulement 2 nœuds en écriture à un instant donné
  • Un nœud witness pour assurer une majorité

Réplication logique

Réplication logique

  • Ajout d'une réplication logique
  • Nœud de rechange déjà prêt
  • Moins de traffic que 2 nouveaux nœuds Master

Haute disponibilité

Haute disponibilité

  • PgBouncer comme pooler de connexion
  • Ha Proxy pour rediriger vers le "bon" Lead Master

Avec sauvegardes

Avec sauvegardes

  • Sauvegardes physique des lead masters
  • Les sauvegardes doivent être testées
  • La base de données n'est pas le seul élément susceptible de tomber en panne
  • Vous n'êtes pas Google
  • Déterminez votre PDMA
  • Déterminez votre DMIA
Image by TanteTati from Pixabay
Unicorns are more real than 0-dataloss and 99.999% availability.
Gülçin Yıldırım Jelínek, Prague, 2019-08-27
Des questions?
Image by Andrew Martin from Pixabay